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remote device driver is coupled to a bus device driver at 
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Description 

BACKGROUND OF THE INVENTION 
s 1. FIELD OF THE INVENTION 

[0001 ] This invention relates to the field of computer systems. 

[0002] Portions of the disclosure of this patent document contain material that is subject to copyright protection. 
The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent dis- 
io closure as it appears in the Patent and Trademark Off ice f ile or records, but otherwise reserves all copyright rights what- 
soever. Sun, Sun Microsystems, the Sun logo, Java, JavaBeans, HoUava and all Java-based trademarks and logos are 
trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. 

2. PACKORQUNP ART 

15 

[0003] Computer systems often include additional devices used to provide additional functionality. These devices, 
often called "peripheral" devices, can include keyboards, printers, scanners, network interface and graphics cards, 
modems, monitors, cameras, and sound input devices; Generally, a device driver is used to control the peripheral 
device. In some network environments, the traditional device driver may not operate correctly. This problem can be 

20 understood by a review of peripheral devices. 

[0004] Peripheral devices are often connected to a computer system through an expansion bus. An expansion bus 
allows the processor of a computer system (via software running on the processor), main memory, and other hardware 
associated with a computer system to control peripheral hardware devices external to the computer system. An expan- 
sion bus consists of conductors for data and control signals, along with hardware support logic chips and possibly 

25 firmware There are a variety of expansion buses such as ISA (Industry Standard Architecture), PCI (Peripheral Com- 
ponent interconnect), S-Bus. VME bus, etc. Each expansion bus defines a certain protocol by which devices that are 
on the bus are accessed. 

[0005] A device driver is software used to control a peripheral device that is coupled with the computer system on 
the bus. A device driver is a program that controls a particular type of device that is attached to your computer. There 

30 are device drivers for printers, display Many device drivers are built into 

an operating system. New device drivers are needed for devices for which the operating system does not already have 
drivers. A device driver converts the more general input/output inistructions of the operating system to messages that 
the device type can understand. In many computer system, device drivers exist as a dynamic link library (DLL) file. 
[0006] Figure 1 illustrates symbolically the interrelation of devices, device drivers, and application programs. 

35 Devices, such as devices A and B, communicate through a bus (such as an expansion bus) to system software. The 
system software includes device drivers (device driver A and device driver B, respectively) implemented in the system 
software kernel. Applications can access the devices through the system software kernel and the appropriate device 
drivers. 

[0007] A problem can arise where, in some network environments, a peripheral device may not be coupled directly 
40 to the computer system through the bus, but rather through a network connection, via a so called "thin" or "ultra-thin" 
client For example, in an environment with a thin or ultra-thin client, it may not be posstole to embed device-specific 
code, such as device drivers, for the large number of devices available. 

3UMMARY OF THE INVENTION 

45 

[0008] The present invention provides a method for devices to be remotely accessed over a network. A remote 
device driver is coupled to a bus device driver at a network client The remote device driver communicates to a remote 
bus proxy to a driver service in the sewer domain. A device manager provides responsibility for discovering services on 
network clients, enabling driver services to use the devices, notifying other driver services of the availability of devices, 
so notifying clinets of the permission to use a device by a service, and tracking connected devices. 

PRIEF DESCRIPTION QFTHE PRAWINOS 
[0009] 

55 

Figure 1 illustrates the relationship of devices, device drivers, and application programs. 
Figure 2 illustrates an embodiment of the present invention. 
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Figure 3 illustrates the virtual desktop environment of the present invention. 
Figure 4 is a block diagram of one embodiment of an HID of the present invention. 
5 Figure 5 illustrates a single chip HID embodiment of the present invention. 
DETAILED DESCRIPTION OF THE INVENTION 

[001 0] The invention is a method and apparatus for accessing remote devices. In the following description, numer- 
ic ous specific details are set forth to provide a more thorough description of embodiments of the invention. It will be 
apparent, however, to one skilled in the art, that the invention may be practiced without these specific details. In other 
instances, well known features have not been described in detail so as not to obscure the invention. 

Virtual PesKtop System Architecture 

15 

[0011] One environment in which the present invention may be applied is in a virtual desktop system. One example 
of such a computer system is described in U.S. Patent Application number 09/063,335 filed April 20, 1998 and entitled 
"Method and Apparatus for Providing a Virtual Desktop System Architecture". In such a system, their is provided a cen- 
tral office metaphor to computing, where features and functions are provided by one or more sewers and communicated 

20 to an appliance terminal through a network. Data providers are defined as "services" and are provided by one or more 
processing resources. The services communicate to display terminals through a network such as Ethernet. The termi- 
nals are configured to display data, and to send keyboard, cursor, audio, and video data through the network to the 
processing server. Functionality is partitioned so that databases, sewer and graphical user interface functions are pro- 
vided by the services, and human interface functionality is provided by the terminal. Communication with the terminals 

25 from various services is accomplished by converting disparate output to a common protocol. Appropriate drivers; are 
provided for each service to allow protocol conversion. Multiple terminals are coupled to the network. Users can enable 
their unique session at any one of the terminals by logging in such as by inserting a "smart card" into a card reader. 
Removing the card disables the session. Re-inserting the card into the same or arty other terminal re-enables the ses- 
sion. 

30 [0012] In the computer system described above, the interfaces for peripheral devices coupled to the human inter- 
face terminal appear over a network protocol and do not involve operating system device drivers in the traditional sense. 
[0013] In this system the funrtionalrty of the system is partitioned be 

sources or services. The display and input device is a human interface device (HID). The partitioning of this system is 
such that state and computation functions have been removed from the HID and reside on data sources or services. In 
35 one embodiment of the invention, one or more services communicate with one or more HIDs through some intercon- 
nect fabric, such as a network. An example of such a system is illustrated in Figure 3: Referring to Figure 3, the system 
consists of computational service providers 300 communicating data through interconnect fabric 301 to HIDs 302. 

Computational Service Providers 

AO 

[0014] In the HID system, the computational power and state maintenance is found in the service providers, or 
services. The services are not tied to a specific computer, but may be distributed over one or more traditional desktop 
systems such as described in connection with Figure 1 , or with traditional servers. One computer may have one or more 
services, or a service may be implemented by one or more computers. The service provides computation, state, and 

45 data to the HIDs and the service is under the control of a common authority or manager. In Figure 3, the services are 
found on computers 31 0*31 1 ,3 1 2,31 3, and 31 4. It is important to note that the central data source can also be providing 
data that comes from outside of the central data source, such as for example, the internet or world wide web. The data 
source could also be broadcast entities such as those that broadcast data such as television or radio signals. 
[0015] Examples of services include X1 1/Unix services, archived or live audio or video services, Windows NT serv- 

so ice, Java™ program execution service, and others. A service herein is a process that provides output data and responds 
to user requests and input. 

[0016] It is the. responsibility otthe service to handle communications with the HID that is currently being used to 
access the given service This involves taking the output from the computational service and converting K to a standard 
protocol for the HID. This data protocol conversion is handled in one embodiment of the invention by a middleware layer, 
55 such as the X1 1 server, the Microsoft Windows interface, a video format transcoder, the OpenGL interface, or a variant 
of the java.awtgraphics class) within the service producer machine. The service machine handles the translation to and 
from the virtual desktop architecture wire protocol. 

[001 7] In an embodiment of the invention, each service is provided by a computing device optimized for its perform- 
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ance. For example, an Enterprise class machine could be used to provide X1 1/Unix service, a Sun MediaCenter could 
be used to provide video service, a Hydra based NT machine could provide applet program execution service. 
[0018] The service producing computer systems connect directly to the HIDs through the interconnect fabric. It is 
also possible for the service producer to be a proxy for another device providing the computational service, such as a 
s database computer in a three tiered architecture, where the proxy computer might only generate queries and execute 
user interface code. 

Interconnection Fabric 

10 [0019] In the invention, the interconnection fabric is any of multiple suitable communication paths for carrying data 
between the services and the HIDs. In one embodiment the interconnect fabric is a local area network implemented as 
an Ethernet network. Any other local network may also be utilized. The invention also contemplates the use of wide 
area networks, the internet, the world wide web, and others. The interconnect fabric may be implemented with a phys- 
ical medium such as a wire or f toer optic cable, or it may be implemented in a wireless environment. 

15 [0020] In one embodiment of the invention, the interconnect fabric provides actively managed, low-latency, high- 
bandwidth communications between the HID and the services being accessed. One embodiment contemplates a sin- 
gle-level, switched network, with cooperative (as opposed to competing) network traffic. Dedicated or shared commu- 
nications interconnects may be used in the present invention. 

20 Human Interface Devices 

[0021] The HID is the means by which users access the computational services provided by the services. Figure 3 
illustrates HIDs 321,322; and 323. A HID consists of a display 326, a keyboard 324, mouse 325, and audio speakers 
327. The HID includes the electronics need to interface these devices to the interconnection fabric and to transmit to 

25 and receive data from the services. 

[0022] A block diagram of the HID is illustrated in Figure 4. The components of the HID are coupled internally to a 
PCI bus 412. A network control block 402 communicates to the interconnect fabric, such as an ethernet. through line 
414. An audio codec 403 receives audio data on interface 416 and is coupled to block 402. USB data communication 
is provided on lines 413 to USB controller 401. 

30 [0023] An embedded processor 404 may be, for example, a Sparc2ep with coupled flash memory 405 and DRAM 
406. The USB controller 401, network controller 402 and embedded processor 404 are all coupled to the PCI bus 412. 
Also coupled to the PGI 412 is the video controller 409. The video controller 409 may be for example, and ATI Ragel 28 
frame buffer controller (or any other suitable controller) that provides SVGA output on line 415. NTSC or PAL data is 
provided into video controller through video decoder 410. A smartcard interface 408 may also be coupled to the video 

35 controller 409. 

[0024] Alternatively, the HID can be implemented using a single chip solution as illustrated in Figure 5. The single 
chip solution includes the necessary processing capability implemented via GPU 501 and graphics renderer 505. Chip 
memory 507 is provided, along with video controller/interface 506. A universal serial bus (USB) controller 502 is pro- 
vided to permit communication to a mouse, keyboard and other local devices attached to the HID. A sound controller 
40 503 and interconnect interlace 504 are also provided. The video interface shares memory 507 with the CPU 501 and 
graphics renderer 505. The software used in this embodiment may reside locally in non volatile memory or it can be 
loaded through the interconnection interface when the device is powered. 

Device Manager 

45 

[0025] The device manager is responsible for brokering devices that are attached to desktop units (HIDs) on the 
interconnection fabric for the purpose of remotely accessing the devices from various services. Since a desktop unit 
has no knowledge of most kinds of devices Jt is not possible for it to understand the semantics of the device, and as a 
result, it is unable to directly control the device. 

so [0026] This means that device drivers should be provided by services running elsewhere on the interconnect 
These services locate devices to be controlled through the device manager, and then they can directly control the 
device through the desktop unit. The device services are treated as the services described above in connection with 
the HID environment; so attention should be paid to connection with the desktop unit, session movement, and possible 
disconnection of the unit from the interconnect. Rnally, since current peripheral bus architectures, such as USB, IEEE- 

55 1 394. and PC bus support- hot-plugging; both services and the device manager should be aware that devices could be 
connected, disconnected; or moved while the desktop unit is functioning and while being controlled by a service. 
[0027] The device manager is also responsible for approving of services, keeping an inventory of devices and their 
controlling services, and locating devices on the interconnect Different management scenarios are made Available 
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including a global device driver service (such as a Solaris™ nexus driver), a per-device driver, or a per-class driver. 
There are also different scopes provided, such as interconnect scope, desktop scope, and session scope. 
[0X928] Since the device management framework is focused on controlling devices, it does not perform desktop unit 
location services, or service and user authentication. These functions are performed by the session manager and the 

5 authentication manager respectively described in co-pending patent application serial number L 

entitled and filed on l and patent application: serial 

number L entitled Method and Apparatus for Remotely Administered Authentication and Access 

Control Services, filed on April 9,1999, and both assigned to the assignee of the present application. Device drivers in 
this context are services that join a session in the way described in the co-pending applications, find their devices using 

w the device manager and deal with the device directly using a protocol with the desktop unit. 

[0029] Device management controls accessfcility of devices to services, thus to users and user programs. It is flex- 
ible enough to handle a wide variety of session and service scenarios from individual devices to all of the devices 
addressed by the desktop unit. This is done by first establishing a connection with the desktop untt using the standard 
session management services. 

75 

Block Diagram 

[0030] Figure 2 gives a block diagram o the overall remote desktop architecture with device management included. 
Components include services 205, the session manager 204, the authentication manager 203, the authentication han- 
20 dler 209 on the desktop side and the bus device driver 208. Also included are the remote device proxy 206, the device 
manager 201, the remote device driver 207, and devices 21 OA - 21 OD coupled to bus 21 1. 

[0031 ] The session manager 204 knows which services are associated with a particular session and manages con- 
nections with the desktop with the help of the authentication manager 203. The authentication manager 203 knows 
which user is requesting access and which session to associate with that user. 

25 [0032] The device: manager 201 uses the association between the user, session and desktop to map device serv- 
ices 205 to particular devices connected to particular desktop units. In the process of doing this, the device manager 
201 can check a policy list 202 to compare what the service is asking for and the user (session) with an administrative 
policy for device access permission, ff appropriate, then the device manager 201 registers the driver service with the 
remote device driver 207, and starts passing device discovery configuration events to the service. 

30 [0033] Since the device manager 201 controls the service with respect to device attachment, the device manager 
201 can inform the service of device loss when a session ends, and, to enforce this, can inform the desktop unit that no 
more control of a particular device is permitted by a particular service. If the service is controlling more than one device, 
then it may still be capable of controlling the other devices. 

[0034] In one embodiment, there is a logically single device manager 201 much like there is a single session man- 
35 ager 204 and authentication manager 203 per interconnect domain. This means that there are single connections 
between the device manager 201 and each of the session manager 204 and the authentication manager 203 the driver 
service connects to the session manager 204 as would any service. It may be possible to plumb the device manager 
201 between the session manager 204 and driver services to add the device management functionality to session serv- 
ices. 

40 [0035] The remote device driver 207 is a standard device driver hosted by the bus device driver 208. The remote 
device driver 207, however, emulates a number of device drivers for the purposes of remote access, so it is likely to own 
all but a few of the devices 21 OA - 21 0D on the desktop unit. As a result, the remote device driver 207 is responsible for 
keeping track of which remote device services 205 go to which devices that are exposed at the bus device driver 208. 
Additionally, the remote device driver 207 picks up configuration events from the bus device driver 208 and reports them 

45 to the device manager 201 for possible connection to a driver service. 

[0036] Finally, the remote device driver 207 has the ability to permit and deny device and unit access by driver serv- 
ices. It maintains filters (given to it by the device manager 201) of interested services that are directly connected to it as 
well as a generic filter to report devices that might not be session-specific. 

[0037] The authentication manager 203 maintains (possibly intermittent) connections with each of the desktop 
so units for the purposes of authenticating users. This connection is used to additionally pass configuration information to 
and from the remote device driver, 207. This connection is not required to be full-time because rt is only needed when a 
session closes down (and then when a session-based policy is in effect), and when configuration events occur for 
devices which do not currently have a service controlling them. 

[0038] The connection between the remote device driver 207 and the driver service is for communicating directly 
55 with the device and reporting errors, device disconnection, or loss of permission. This connection can be intermittent 
because the connection may be lost when a session changes or when a device is no longer available. 
[0039] The bus type determines the protocol between the service (the bus proxy 206) and the remote device driver 
207. The remote device driver's architecture and interface to the bus driver is also determined by the bus driver. Finally, 
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the device description format, parts of the device ownership policy, and address space are also controlled by the bus 
type. 

[0040] It is assumed that it is possible to track a user's authentication record from a session so it is possible to pro- 
vide access to devices and units based on user identity. It is also assumed that it is possible to derive the desktop unit 
s interconnect address from a session to enable communication with the desktop unit, to provide access to devices based 
on the identity of the desktop unit, and to track device assets based on desktop unit. 

Device manager 201 

10 [0041] The Device manager 201 is responsible for brokering devices to services. In doing this, it needs to intercede 
between the remote device driver 207 and the driver service. The following is a step-by-step procedure for permitting a 
driver service to access a remote device: 

1. When a device request (register) is received from the driver service, it is compared to the device access policy 
is by comparing each field of the request to the policy. If there is a field that is specified in the policy (e.g. has a specific 

value and is not wild-carded), and the field does not match the field in the request, then the request is rejected. 
Incomplete matches are enabled for the class, model, and serial number. 

2. The attached device data is scanned for a match with the device request. Device requests match devices for the 
20 purpose of reporting back to the driver service. If there is an attached device that matches, then a device status 

(connect) message is sent to the driver service; Otherwise, no response is generated at this time. 

3. A received device request (register) is stored in the list of registered services. 

25 4. If a driver services wishes to be the configuration master of the device, it requests configuration write permission 
with a device request (configure) message: If there is no current configuration service, then the attached device 
data is updated and a driver registration (configure) message is sent to the desktop unit. Otherwise, the request is 
rejected. * 

so 5. If the driver service wishes to use a particular device unit then a device request (allocate) is received from the 
service which signifies the server connection number (e;g. Server socket) to be used for unit connection to this 
driver service. Otherwise, the device (or unit) remains available for other services to allocate; 

6. When a unit is allocated, then a driver registration (allocate) message is sent to the desktop unit 

35 

7. When a Device discovery message Is received, then the device is added or removed from attached device data. 

8. When a device is added to the device data, the selection data is rescanned for a match, and device status (con- 
nect) messages may be generated if there are matches. 

40 

9. Receiving a device request (allocate) renews the lease on a device unit. 

10. When a device is removed from the device data, the selection data is re-scanned for matching services. If a 
service's selection lifetime is met, then the service's registered selection is removed. 

45 

1 1 . When the connection with the driver service is tost, or a device request (unregister) is received, or the selection 
lifetime criterion is met, then the service's registered selection is removed. 

1 2. If a registered selection is removed, then a driver registration (remove) message is sent to the desktop unit. 

50 

13. When the connection to the desktop unit is lost, the devices connected to that unit are removed from the list. 
Any interested services may have their registered selections removed if the selection lifetime is met. 

14. If a service's lease on a device expires or a session lease expires, then a Driver Registration (remove) message 
55 is sent to the desktop unit. 
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[0042] The device access policy is an external file or database that is compared to device access requests to deter- 
mine if a request is valid. It contains the following fields: 

5 

a. user (session), 

b. server (e.g. IP address), 

w c. device selection information: 

i. class (or none), 

ii. vendor (or none), 

iii. model (or none), 

is iv. serial number (or none). 

d. selection scope (session desktop unit, interconnect global), 

e. selection lifetime (session connected, device disconnect, permanent), 

so 

f. connection lifetime (session connected, session delayed, device lease), 

g. maximum lease duration (in case session delayed or device lease is enabled). 

26 [0043] Any of the f ields can be left blank, meaning any value in the request will match that field. In order for a com- 
plete match, all specified fields should be matched. 

[0044] Class, model, and serial number allow incomplete matching if the amount specified in the policy matches the 
first part of the request string. 

Unions are allowed for lifetime values (e.g. session connected or permanent). 

30 

Device Access Request 

[0045] The device access request is used by driver services to register and unregister device searches and set the 
communication capabilities with the desktop unit. The server address and the session number are derived from the ses- 
35 sion manager 204 connection. This request has several forms: (parenthesized expressions are examples from the USB 
configuration specification). 

a. register: 

40 i. class, 

ii. vendor, 

iii. model, 

iv. serial number, 

v. selection scope, 
45 vi. selection lifetime, 

vii. connection lifetime, 

viii. lease duration. 

b. configure: 

so 

i. desktop unit address, 

ii. device address, 

iii. service socket, 

55 c. allocate: 

i. desktop unit address, 

ii. device address, 
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iii. unit address, 

iv. service socket. 

d. release 

5 

i. class, 

ii. vendor, 

iii. model, 

iv. serial number, 
10 v. selection scope, 

vi. selection lifetime, 

vii. connection lifetime. 

Pevire Piscpyery 

15 

[0046] Device discovery is used by the desktop unit to report when devices change state - connected, discon- 
nected, owned, released. The desktop unit interconnect address is derived from the authentication manager 203 con- 
nection. This request has several forms: 

20 a. connect (sent on connection, ownership or release): 

i. bus type (e.g. USB, IEEE- 1394), 

ii. device address, 

iii. device class (bDeviceClass+bDeviceSubCIass+bDeviceProtocol, 
25 Module_SpecJd_+ModuIe_SW_Version). 

iv. vendor (idVendor, Module_VendorJd), 

v. model (idProduct+bcDevice, Module_HW_Version), 

vi. serial number (iSerialNumber, ModuleJJniqueJd), 

vii. configuring server address, 

30 viii. configuring server socket number, 

ix. Units (Interfaces in USB): class, controlling server address, controlling server socket number. 

b. disconnect: 

35 i. bus type, 

ii. device address. 

Processing 

40 [0047] 

1. Tracks the connection and disconnection of devices for all desktop units on an interconnect 

2. Keeps a list of all devices currently attached devices on all functioning desktop units on an interconnect. This list 
45 includes (example mappings: USB, I EC/I S0 13213 [e.g. IEEE- 1394]): 

a. Desktop unit interconnect address, 

b. bus type (e.g. USB, IEEE-1394), 

50 

c. device address, 

d. device class (bDeviceClass-tbDeviceSubClass+bDevice Protocol, Mod Je_SpecJd+Modu!e_SW_Version), 
55 e. vendor (id Vendor, Module_VendorJd), 

f. model (idProducHbcdDevice, Modute_HW_Version) l 
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g. serial number (iSerialNumber, ModuieJJniqueJd), 

h. oonfiguring service, 

5 i. configuring service socket number, 

j. Units (Interfaces in USB): 

i. class (bimerfaceaass^lnterfaceSubClass^t)lnterfaceProtocol, Unit_SpecJd+Unrt_SWJ/ersion), 
io ii. controlling service, 

iii. controlling service socket number. 

3. keeps a list of all driver services registering interest in devices: 
is a. user (Authentication manager 203 record, session), 

b. server (e.g. IP address), 

c. other identification information (e.g. process ID, program name provided by the service). 

20 

d. device selection request: 

i. class (or none), 

ii. vendor (or none), 
25 iii. model (or none), 

iv. serial number (or none), 

e. selection scope (session desktop unit, interconnect global), 

30 f. selection lifetime (session connected, device disconnect, permanent), 

g. connection lifetime (session connected, session delayed, device lease), 

h. lease duration. 

35 

4. Informs driver services when a candidate device becomes available whether or not rt is in use by another service 
(all approved services can read a device's configuration space). 

5. Accepts device access requests from services. Operational device access requests apply only to individual units 
40 so multiple services can control a single device. 

6. Controls device access permissions. 

7. Compares the device access request to the device access policy. 

45 

8. After authorization, registers a driver with a desktop unit. 

9. In case of failure, all interested services are reconstructed and each desktop unit queried on a time-available 
basis for its current list of devices and owning services. External programs can snapshot the device manager 201 

so state e.g. for inventory purposes, but that is not considered core or critical device manager 201 functionality. Device 
manager 201 failure does imply the temporary loss of the ability to connect some services to some devices. 

10. Driver services may register before the particular device requested is available (e.g. in use or disconnected). 

55 
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Outputs 

1. Device Status 

s [0048] The device status message is sent to the driver service when a device is connected or ownership changes. 
Disconnect events come directly from the desktop unit. The message includes the data: 

a. Desktop unit interconnect address, 

70 b. bus type (e.g. USB, IEEE-1 1394), 

c. device address, 

d. device class (bDeviceQass+bDeviceSubClass+bDeviceProtocoi, Module_SpecJd+Module_SW_Version), 

15 

e. vendor (idVendor, Module_VendoMd), 

f. model (idProduct+bdcDevice, Module JWVVersion), 
20 g. serial number (iSerial Number, Module_Untque_kf), 

h. configuration available, not available, owned, 

i. Units (Interfaces in USB): 

25 

i. class, 

ii. control available, not available, owned. 

2. Driver Registration 

30 

[0049] The driver registration message is sent to the desktop unit to attempt to allocate a device on behalf of a serv- 
ice. There are three forms to this message: 

a. configure - sets configuration control to a particular service, 

35 

b uncortf igure - removes configuration control from a particular service, 
c. allocate - sets unit control to a particular service, 
40 d. remove - removes unit control from a particular service. 
[0050] All three have the same arguments: 

a. bus type, 

45 

b. device address, 

c. unit address (zero for configure and unconfigure), 
so d. server address, 

a server socket number. 
Driver Service 

55 

[0051] The driver service is the client to device management, and created by an external party. 

[0052] The driver service needs to completely control the device; e.g., Implement a complete device driver. As 

such, it is the responsible party for creating device requests. The driver service uses the remote bus proxy 206 to help 
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structure itself with respect to a session and handling the device protocol. 

[0053] After describing a controllable device to the device manager 201 , the driver service waits for device status 
messages for the purpose of collecting the desktop unit address and the device number. When the device status mes- 
sage is received, then the driver service is free to read the device's configuration space using the remote bus proxy 206. 
5 If the device is found to be inappropriate, the driver service waits for more device status messages, and optionally 
closes the socket it used to access the desktop unit. If the connection is still open and the device is unplugged, then the 
driver service receives remote device data that reflects this. 

[0054] H the driver service wishes to fully access the device, it should first determine if there is a current configura- 
tion, if there is, then it simply can start sending device requests to open units. If there is not a current configuration, then 
10 the service needs to become the configuration owner first. If the driver service is the configuration owner, then it should 
set the configuration if the bus and/or device require that to be done. 

[0055] If there are already open device units, then it is possible that the original configuration owner has given up 
control of the configuration, but the configuration cannot change until all of the units are dosed. 
[0056] After a unit is opened, then read and write operations can happen on any of the conduits associated with the 
is unit; the driver is the sole owner of that unit 

[0057] If a session state change Is detected, the device manager 201 assumes that the driver service will follow its 
policy and either continuing to service.device status requests, and controlling the device, or drop the device and wait for 
the session to establish itself with a new desktop unit. The device manager 201 additionally enforces this. 
[0058] When the driver service is done with a device, it releases all of its units using a device request (release) corn- 
so mand. If it was the configuration owner, then it should release its configuration using a similar command. If the lease 
expires on the device, the socket is dosed, or if the device is disconnected, then all of this happens automatically at the 
desktop unit. 

Inputs 

[0059] 

1. Device Status. 

2. Bus-specific remote device data. 

30 

Processing 
[0060] 

35 1 . Device-specific services register from within the context of a session, even if that is a special administrative ses- 
sion. 

2. The driver service is responsible for describing the devices it can drive. This can be more than one device. 

40 3. It is acceptable for driver services to discovery a device and to probe its configuration space without either 
becoming the configuration owner or opening any units. 

Outputs 

45 [0061] 

1 . Device Requests, 

2. Bus-specific remote device data. 

so Remote Bus Proxy 206 

[0062] The remote bus proxy 206 is an easy-to-use interface for both the device manager 201 and the remote 
device driver 207. The remote bus proxy 206 converts function calls into protocol for both of these. 
[0063] Since the remote bus proxy 206 handles the remote device driver 207, its interfaces are necessarily bus- 
55 specific. For an example of a remote device driver 207, refer to the USB remote proxy 206 interface below. 
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USB Bus Binding 
Device Discovery Formats 
s [0064] 

1 . bus type: USB=OxO00 1 xxxx where 65536 USB buses are allowed. 

2. device address: 1-127. 

3. device class (bDeviceClass+bDeviceSubClass+bDeviceProtocol): 24 bits, variable in 8-bit increments. 
10 4. vendor (idVendor) : 1 6 bits. 

5. model (klProduct+bcdDevice): 32 bits, variable in 16-bit increments. 

6. serial number UNICODE string, optional, may vary according to LOCALE. 

7. configuring service: IP address. 

8. configuring service socket number: 16 bits. 
is 9. Units (Interfaces in USB): 

a. class (blnterfaceClass+blrterfaceSubClass^lrrterfaceProtocol): 24 bits, variable in 8-bit increments. 

b. controlling service: IP address. 

c. controlling service socket number: 16 bits. 

so 

Remote Device Protocol 

[0065] Because all of the data for a session is being multiplexed onto a single socket, it is important to use a call- 
response protocol similar to the basic USB protocol. This keeps backpressure on the USB bus and not on the TCP con- 
25 nection because only one transaction at a time is allowed on an endpoint The entire protocol is done in two phases. 
One to send data or commands and another to receive data or status. Only disconnect events are asynchronous (but 
you can have only onel). 

The well-known port for USB transactions is 5498. 
30 #define UT_USB_PORT5498 

[0066] The first data sent is a 16-bH magic number followed by a 16-bit command. After that all data transfer is 
done in an even number of 4-byte words. The length ol the command is derived from the command and then rounded 
up to make an even number. 

35 

#define UT_USB_MAGIC0x5554/* VT 7 



typedef struct ut_usb_cmd { 

uintl6_t magic; 

uintl6_tcmd; 

uintl6_t val; 

uintfLt addr; 

uint8_t endp; 
I ut_cmoLt; 



so [0067] Val is an argument for the particular command, addr is the device address from 1 -1 28. and endp is the end- 
point (unit in Device Management parlaise) number from 0-15. 

[0068] The IN command is used to request data from an endpoint, and for that data to be returned to the service. 
Val encoded the size of bytes of the desired read, or the amount of the data returned. 

55 #define UT_USB_IN0x0096 

[0069] The STATUS command is used to return status for OUT commands, or error status for bad IN commands. 
Error codes are found in the val field and are TBD, but are extended from the OHCI transfer error codes. There will be 
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special error codes to designate that the endpoint is inaccessable, and to designate that the device is inaccessable 
and/or disconnected if the endpoint is zero. Special error codes will not conflict with operational error codes. 

^define UTJJSB_STATUS0x004b 

5 

[0070] The OUT command is used to write data directly to an endpoint. The length of the transfer is encoded in the 
val field. The response from the device is always with a status command 

#define UTUSB_OUT0x0087 

10 

[0071] The SETUP command is tor sending a control transfer. The 8 bytes immediately following the header 
describe the control command. Val encodes the length of the data following and should exactly equal the value in bytes 
6 and 7 of the control command. If the command is a read {bmRequestfype & TRANS_RE AD) , then val should be zero. 

is ^define UT_USB_SETUP0x00b4 

A.3 Remote Interface Proxy 206 

[0072] 



typedef struct ut_ubus { 
char 'session; 
char * target; 
25 nvSession nvsession: 

int sessional t; 
in t net; 

uLcmcLt and; 
so uintftjbufl2048] 
) ut_ubus_t; 

typedef struct ut_pipe { 

uLubusLt *ubusp; 
35 intdev; 

intendpt; 
J ulLpipe_t; 

uLubus^t •uLusb J>us(char 'session, char *target, int threaded); 
40 void ut.usb_done(uL\ibus_t *ubusp); 
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ut_pipe_t *ut_usb_open(ut_ubus_t *ubusp / int dev, int endpt); 
voit ut_usb_dose(ut_pipe_t *pipep); 

5 int uL.ccmtroLread(ut_ubus_t *pipep, int flags, int request, int value, int index, int length, 
uint8_t »data); 

int ut^controLwrite(ut^pipe^t *pipep, int flags, int request, int value, int index, int length, 
w uint8_t Mata); 

int ut_sendjbulk(ut_pipe_t *pipep, uint8_t »data, int len); 
int ut_receive_bulk(utL.pipe_t *pipep, uint8_t »data, int len); 

15 int ut_registerjiubevent(ut_ubus.t *ubusp, 

void (*) (uLubus^t *ubusp, void •arg, uintl6_t val), 
void *arg); 

int ut_registerjnterrupt(ut_pipe_t *pipep, 
so void (*) (ut-Pipe_t *pipep, void *arg, int len), 

void *arg, int size, void *ptr); 

ut_cmd_t *ut.usb^etevent(ut w ubus„t *ubusp); 

25 

[0073] It is responsible for sending requests and data to the device manager 201 and to the remote device driver 
207. (t also provides call-back routines for connect and disconnect events, and any other asynchronous event that the 
bus protocol dictates (e.g.. USB interrupts). 




[0074] 



35 1. Device status, 

2. Bus-specific remote device data. 

Processing 

40 [0075] Device manager 201 function should not be required to maintain current device connections. In case of 
device manager 201 failure, connecting should be retried- When a new connection is established, device request data 
should be sent to the device manager 20 1 for database rebuild. 

Outputs 

45 

[0076] 

1 . Bus-specific device semantics, 

2. Device Request, 

so 3. Bus-specific remote device data. 

Remote device driver 207 

[0077] The remote device driver 207 maintains relationships between the device manager 201, the requesting 
55 services and the actual bus device driver 208. It can tap all configuration activity on the bus. Its two primary functions 
are to map configuration information to and from the device space and to convert protocol to and from device data. 
When a device is plugged in, unplugged, or the ownership of a device changes, the remote device driver 207 should 
send a device discovery message. 
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[0078] When a device is unplugged or becomes inaccessible to a particular service, then it should send an unplug 
message over the socket to the driver service and disable that device connection for that service (although it should not 
remove all of the device connections if they are not all invalid). If the connection to the driver service is lost it should free 
all of the resources being held by that service and notify the device manager 201 . 

[0079] When the device manager 201 sends a driver registration message, the remote device drive enables the 
designated port for the designated resource. If the designated resource is not available, the remote device driver 207 
sends a device discovery message to the device manager 201 reminding it who currently owns that resource. If the 
resource is available, the resource is available, the resource is allocated and enabled, and a device discovery message 
is sent to the device manager 201 to indicate the new owner. 

[0080] The device manager 201 will, from time to time, send driver registration messages indicating that a service 
no longer has access to a device or unit. In this case, that resource is deallocated, a disconnect message is sent to the 
driver service, and a device discovery message is sent to the, device manager 201 to indicate that the resource has 
been released. 

[0081 ] If the connection to the device manager 201 is lost then this is retried until connection is reestablished, then 
all of the current device data is sent to the device manager 201 using device discovery messages. 

Inputs 

[0082] 

20 

1. Bus-specrfic commands and data. 

2. Driver Registration. 

Processing 

25 

[0083] 

1 . In order to realize one connection per service per desktop unit, it is necessary to perform flow control at the bus 
level rather than at the connection level. 

30 

2. For accounting purposes, a remote device driver 207 reports devices which it does not manage or are currently 
not connected to a service to the device manager 201 . 

3. It is possible for the configuration space of all devices, including devices used internally to the desktop unit, to be 
35 queried, but if a device is in use (either locally or remotely) it is not possible to change the configuration (other than 

to connect to a service in the case of an unused device) nor to transfer operational data to or from these devices. 

4. If there are already open device units, then it is possible that the original configuration owner has given up control 
of the configuration, but the configuration cannot change until all of the units are closed. 

40 

5. Remote device driver 207s should be able to deny connections to devices from services directly. This is impor- 
tant for policy enforcement. 

6. Device manager 201 function should not be required to maintain the list of current device connections. 

45 

7. In case of device manager 201 failure, connecting should be retried. When a new connection is established, all 
device discovery data should be sent to the device manager 201 for database rebuild. 

8. Informs all interested driver services when a device is disconnected whether or not they have exerted any control 
so over the device. 

Outputs 

[0084] 

55 

1 . Bus specific status and data. 

2. Device Discovery events. 
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[0085] 

5 1 . The Device manager 201 uses the authentication manager 203 connection for a secure, and ubiquitous connec- 
tion to all desktop units. 

2. The device manager 201 uses the session manager 204 connection to be sure that the session that is making 
requests is currently attached to the desktop unit it wants to control. 

3. The device manager 201 does not authenticate individual users. It is up to programming on the device manager 
io 201 target platform to provide a connection into the device manager 201 which can authorize individual users. 

Communication Interfaces 

[0086] " - — — - '■ 

15 

1. All remote interfaces use sequenced, reliable byte streams. 

2. All communications interfaces depend on the installed networking infrastructure, which is not specified. Initial 
versions are for TCP/IP at all interfaces. 

20 

[0087] The features disclosed in the foregoing description, in the claims and/or in the accompanying drawings may, 
both separately and in any combination thereof, be material for realising the invention in diverse forms thereof. 

Claims 

25 

1 . A device manager for providing a device driver for a device comprising; 

a device service for requesting a device; 
a remote bus proxy for communicating with a client device; 
30 a remote device driver coupled to a client device; 

a device manager for controlling communications between said device service and said remote device driver. 

2. An apparatus for providing access to one or more remote devices over a network, comprising: 

35 a remote device driver coupled to one or more devices; 

one or more driver services configured to remotely control one or more of said devices, wherein said remote 
device driver tracks which of said one or more driver services communicates with which of said one or more 
devices; and 

a device manager configured to register one or more of said device services with said remote device driver to 
access one or more of said devices. 

3. The apparatus of claim 2, wherein said one or more driver services and said device manager reside in a server 
domain coupled across a network to said remote device driver. 

45 4. The apparatus of claim 2, further comprising: 

a bus device driver coupling said remote device driver to said one or more devices; and 
a bus proxy coupling said one or more driver services to said remote device driver. 

so 5. The apparatus of claim 2, further comprising: 

a session manager configured to associate one or more sessions with one or more of said driver services; and 
an authentication manager configured to associate one or more sessions with one or more clients. 

55 6. The apparatus of claim 2. wherein said device manager is configured to enforce a device access policy for regis- 
tering said one or more driver services. 

7. The apparatus of claim 2, wherein said device manager maintains an inventory of devices and respective control - 
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ling driver services. 

8. The apparatus of claim 2, wherein said device manager is configured to locate said one or more devices. 

9. The apparatus of claim 2, wherein said device manager is configured to notify a first driver service of loss of a first 
device when an associated session ends. 

1 0. The apparatus of claim 9, wherein said device manager is further configured to notify said remote device driver that 
said first driver service is no longer permitted to control said first device. 

1 1 . The apparatus of claim 2 wherein said remote device driver is configured to notify said device manager of a con- 
figuration change in said one or more devices. 

12. The apparatus of claim 2, wherein said remote device driver comprises a filter for permitting and denying access 
15 by one or more of said driver services, said filter provided by said device manager. 

13. A method for providing access to one or more remote devices over a network, comprising: 

a device manager receiving a device request from a driver service; 
20 said device manager registering said driver service with a remote device driver; and 

said driver service communicating with a remote device via said remote device driver. 

14. The method of claim 13, further comprising said remote device driver sending device configuration information to 
said device manager. 



25 



30 



35 



1 5. The method of claim 1 3, further comprising a bus device driver exposing one or more devices to said remote device 
driver. 

16. The method of claim 13, further comprising: 



associating a session with said driver service via a session manager; and 
associating said session with a client via an authentication manager. 

17. The method of claim 13, wherein registering said driver service comprises enforcing a device access policy. 

18. The method of claim 13, further comprising maintaining in said remote device, driver an association between one 
or more devices and one or more driver services. 

19. The method of claim 13, further comprising said device manager maintaining an inventory of devices and respec- 
40 tive controlling driver services. 

20. The method of claim 1 3, further comprising said remote device driver permitting and denying access to one or more 
devices based on a filter provided by said device manager. 

45 21 . The method of claim 13, further comprising said device manager locating one or more devices on said network. 

22. The method of claim 13, further comprising said device manager notifying said driver service of loss of said device. 

23. The method of claim 22, wherein said loss of said device is in response to the closing of an associated session. 

60 

24. The method of claim 22, further comprising said device manager notifying said remote device driver that said driver 
service is no longer permitted to control said device. 

25. A computer program product comprising: 

55 

a computer usable medium having computer readable program code embodied therein for causing a computer 
to provide access to a remote device across a network, said computer readable program configured to cause 
said computer to perform the steps of: 
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receive a device request from a driver service; 

register said driver service with a remote device driver; and 

enable said driver service to communicate with a remote device via said remote device driver, 

26. The computer program product of claim 25, wherein said computer readable program code is further configured to 
cause said computer to receive device configuration information from said remote device driver. 

27. The computer program product of claim 25. wherein said computer readable program code is further configured to 
cause said computer to; 

associate a session with said driver service via a session manager; and 
associate said session with a client via an authentication manager. 

2a The computer program product of claim 25, wherein registering said driver service comprises enforcing a device 
access policy. 

29. The computer program product of claim 25, wherein said computer readable program code is further configured to 
cause said computer to maintain an inventory of devices and respective controlling driver services. 

30. The computer program product of claim 25, wherein said computer readable program code is further configured to 
cause said computer to provide a filter to said remote device driver for use in permitting and denying access to one 
or more devices. 

31. The computer program product of claim 25, wherein said computer readable program code is further configures to 
cause said computer to locate one or more devices on said network. 

32. The computer program product of claim 25, wherein said computer readable program code is further configured to 
cause said computer to notify said driver service of loss of said device. 

33. The computer program product of claim 32, wherein said loss of said device is in response to the closing of an 
associated session. 

34. The computer program product of claim 32 wherein said computer readable program code is further configured to 
cause said corrputer to notify said remote device driver that said driver service is no longer permitted to control 
said device. 
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FIGURE 1 
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